Those atrocious linking errors :) I wish there was a way to throw an error at preprocessor/link time without having to add explicit checks

Yeah, this is the second time i spend significant amount of time to these issues.

Should we just remove FLOAT? do we anticipate using it for MIP?

I think we ought to be careful with the implicit cast to size_t performed here. The C++ standard states that any value that cannot be represented in the target cast type yields undefined behavior:

Real floating-integer conversions
A finite value of any real floating type can be implicitly converted to any integer type. Except where covered by boolean conversion above, the rules are:

The fractional part is discarded (truncated towards zero).
If the resulting value can be represented by the target type, that value is used
otherwise, the behavior is undefined.
int n = 3.14; // n == 3
int x = 1e10; // undefined behavior for 32-bit int

I think this mean there might be issues in the case of negative and large (>1e20) assignments. It's probably better to compute the hash in a bitwise manner

Good catch, fixed!

I think this is a 32-bit hash, with 64-bit values this might not work properly

Thanks fixed!

I seriously doubt we will ever use anything but FP64, but in the rare case we instantiate the solver with f_t=FP32, this is going to break/behave badly. We might want to add a static_assert to make sure sizeof(f_t) == sizeof(size_t) in order not to cause issues if users decide to try out FP32

okay let me add the static assert here.